Sometimes the synchronous calculation of the rectangular area fails

memory leak

saveState() may use the floatingDockContainer to be deleted

remove dock container

…et) call

* fix side bar state being incorrect during restore

* isVisible is invalid during restore state

* Make visibleTabCount function consistent with hasVisibleTabs. Add a bit of documentation.

---------

Co-authored-by: Syarif Fakhri <fakhri.s@duerr-ndt.com>

…SideBar::visibleTabCount() and CAutoHideSideBar::hasVisibleTabs()

…; with QWidget::activateWindow

Thank you

…ing back to QApplication (#812)

* Fix ADS_VERSION support for builds without git dependency

- Move CMAKE_MODULE_PATH outside if(NOT ADS_VERSION) block so it's always available
- Parse ADS_VERSION to set PROJECT_VERSION_* variables for Versioning.cmake
- Update Versioning.cmake to use predefined version when available, fallback to git

This allows building with -DADS_VERSION=X.Y.Z without requiring git repository.

Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

* Add ADS_PLATFORM_DIR option to customize output directory

Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

---------

Co-authored-by: ArtemNabok <nabok.artem@yandex.ru>
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

…a floating widget that contains only one single visble dock area (#816)

* Initial plan

* Fix drawing artifacts when content widgets call winId()

When a content widget (e.g. VTK/OpenGL) calls winId() to get a native
window handle, Qt propagates native-window creation up the ancestor chain.
This makes CDockWidget, CDockAreaWidget, and CDockContainerWidget all
become native OS windows unexpectedly. Reparenting these native dock
widgets during floating or resizing then causes drawing artifacts.

Fix: set Qt::WA_DontCreateNativeAncestors on the content widget in
CDockWidget::setWidget() to stop native-window creation from propagating
up into the dock hierarchy.

Co-authored-by: RubendeBruin <34062862+RubendeBruin@users.noreply.github.com>

* Fix docking system to handle mix of native and alien Qt widgets

Three targeted fixes for the native/alien widget mixing problem:

1. Revert WA_DontCreateNativeAncestors from CDockWidget::setWidget().
   Setting it on the content widget created a broken native-inside-alien
   hierarchy: the QScrollArea (alien) could not clip its native child, so
   content escaped the scrollbox bounds; and alien CAutoHideDockContainer
   could not appear above the native content widget.
   Allowing natural propagation means QScrollArea also goes native, and OS
   parent/child window clipping works correctly.

2. Fix CDockContainerWidget::removeDockArea to use internalWinId() instead
   of testAttribute(WA_NativeWindow). WA_NativeWindow is only set when a
   widget is explicitly made native; widgets that became native through
   upward propagation from a descendant calling winId() have a real native
   window handle (internalWinId() != 0) but WA_NativeWindow may be unset.
   Setting their parent to nullptr would create a free-floating invisible
   OS window and cause drawing artifacts.

3. Fix CAutoHideDockContainer::collapseView: when the parent dock container
   is native but the auto-hide panel is still alien, promote the panel to a
   native window (winId()) before raise(). The OS always renders native
   child windows above a parent window's painted alien content, so an alien
   auto-hide panel can never appear above native sibling dock areas. Once
   the panel has its own OS-level window, raise() operates on OS Z-order
   and correctly places it above native content siblings.

Co-authored-by: RubendeBruin <34062862+RubendeBruin@users.noreply.github.com>

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>

…rnal hide/show cycle by QWebEngineView. (#821)

Co-authored-by: AlbertoM <ma-robox@users.noreply.github.com>

… deletion (#823)

Add preferredAutoHideSideBarLocation property to CDockWidget that allows
applications to specify where a widget should be pinned, overriding
geometry-based detection. When unpinning, widgets with the same preferred
location merge as tabs instead of creating new splits.

Default is SideBarNone (existing geometry-based behavior preserved).

- If compiling with flag [-Werror,-Winconsistent-missing-destructor-override]

Resolve: #833

In DockManagerPrivate::restoreStateFromXml() the floating widgets were
removed via removeDockContainer() and then queued for deletion with
deleteLater(). When ~CDockContainerWidget() ran it would call
removeDockContainer() a second time on the same container, tripping the
Q_ASSERT(removed == 1) check in CDockManager::removeDockContainer().

Switch to CDockContainerWidget::removeFromDockManager() (introduced in
upstream 544c624) so the container's back-pointer to the manager is
cleared up front and the destructor becomes a no-op for the manager
side. This keeps the LP360_AI workspace restore path crash-free until
the equivalent fix lands upstream.

On Linux/X11 the CDockManager constructor connects a handler to
QApplication::focusWindowChanged that, on every focus-window change,
calls raise() on the dock manager, on every floating widget, and on
the newly focused window. The original intent (#722) was narrower:
bring the application and its floating widgets to the foreground only
while a floating dock widget is being dragged over another application.

Reacting to *every* focus change makes this a self-sustaining loop.
raise() restacks top-level windows, which on X11 can make the window
manager move focus, which re-emits focusWindowChanged and re-enters the
handler. Because all windows are raised on every pass, the z-order
never reaches a stable state, so the windows keep restacking - visible
as continuous flicker. It gets worse the more floating widgets exist,
since each pass raises more windows and generates more focus
transitions. The later QMainWindow/QDialog/CFloatingDockContainer type
test only narrows which focus changes start the loop; once started it
still runs unbounded (#785).

Fix: gate the entire raise block on a floating widget actually being
dragged. Outside a drag the handler now returns immediately and issues
no raise() calls, so it can no longer feed itself - no restacking, no
flicker. The foreground behaviour during a real drag is unchanged and
ends naturally when the drag finishes.

ADS already tracks this state internally
(FloatingDockContainerPrivate::DraggingFloatingWidget); this exposes it
through a small public accessor:

  bool CFloatingDockContainer::isDraggingActive() const;

Fixes #785.

* add dark versions of resource files

* reload stylesheet on theme change

* adjust dock overlay colors for dark mode, refresh dock overlay colors when theme changes

* follow application palette instead of system scheme, remove Qt version constraints, add legacy behavior settings

* fix text color of focused tab label for highlighting stylesheets

* fix missing tab menu icon in focus highlighting stylesheet

…window drag (#844)

Qt Advanced Docking System could not dock on Wayland: a client cannot position
top-level windows and the global cursor position is unreliable, so the
mouse-tracked floating-widget drag never worked. This adds Wayland docking by
combining two mechanisms, selected by whether the drag stays inside its source
window.

Native cross-window drag (xdg_toplevel_drag_v1):
- CFloatingDockContainer::startPlatformDrag() runs a compositor-driven drag via
  QDrag with the Qt main-window-drag MIME types, so a floating window is moved
  by the compositor and can be dropped onto another window.
- Drop targets handle the drag in CDockContainerWidget dragEnter/Move/Leave/drop
  events, with a recorded drop-candidate fallback for compositors that do not
  deliver a drop event over the dragged window.
- The drop overlays (CDockOverlay) and the in-window drag preview are rendered
  as child widgets of the relevant top-level window, because a Qt::Tool
  top-level cannot be positioned in screen coordinates on Wayland.
- Floating containers use a native window with no parent on Wayland, and the
  DockManager stays-on-top emulation that would recreate window surfaces is
  skipped.

In-window preview, native only when leaving the window:
- While the cursor stays inside the source top-level window, a drag uses the
  familiar in-window CFloatingDragPreview plus drop overlays (no new window),
  driven by the reliable event-supplied position from the grabbing tab or title
  bar and confined to the source container.
- When the cursor leaves the window, the preview is torn down and a real
  CFloatingDockContainer is created and handed to startPlatformDrag() while the
  press's implicit pointer grab is still held - a single continuous gesture.
  This covers both the tab (CDockWidgetTab) and title-bar (CDockAreaTitleBar)
  drag paths and applies to rearranging widgets inside floating windows too.
- The attach offset that places the new window under the cursor is only honored
  while the toplevel is unmapped, so startPlatformDrag() runs QDrag::exec()
  without waiting for exposure, and the caller passes the surface-local grab
  offset explicitly - shifted by the window frame top and left margins - instead
  of deriving it from the unmapped window's (meaningless) geometry, so the
  grabbed content point stays under the cursor on both axes.

Style sheets and overlay lifetime:
- A Wayland floating container has no parent widget, so it does not inherit the
  dock manager's effective style sheet through the widget hierarchy. The style
  sheets along the dock manager parent chain are applied explicitly when the
  window is created, and CDockManager re-applies them on QEvent::StyleChange so
  a floating window keeps matching the docked content when the style sheet
  changes at runtime (an application-wide qApp style sheet is still applied by
  Qt automatically).
- The drop overlays are reparented into the top-level window they are shown over
  and reparented back to the dock manager's window when hidden, so a
  dock-manager-owned overlay is never left as a child of a transient floating
  window that gets destroyed.

Saved layouts restore the docked arrangement, floating-window sizes and their
maximized/normal state, but not floating-window or main-window positions:
Wayland does not let a client position its own top-level windows, so the
compositor decides where restored windows appear.

Non-Wayland platforms (X11, Windows, macOS) are unaffected: every behavioral
change is gated on internal::isWayland(), and the shared drag-preview code keeps
using QCursor::pos() and the existing window positioning off Wayland.

Co-authored-by: Agent 01 <agent@jetperch.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…rectly from auto-hide state

…thon (#848)

* Attempt to fix

* Removed debug

* whoopsie

* Const qualifiers

* rEVERt "Const qualifiers"

This reverts commit 364a83c.